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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 



Introduction 



The present document describes the main type of IMS based IPTV Customer Devices that take part in Customer 
Premises Network in terms of general architecture and in terms of reference points with the NGN and CNG. 
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Scope 



The present document defines the stage 2 Customer Network Devices for IPTV services (IPTV-CND) specifications; It 
is therefore addressing the overall architecture of the customer network device (CND) enabling the IPTV service 
consumption. The architectural definition is covering both transport and service layer related functionalities. The 
reference points between the CND and the Customer Network Gateway (CNG) are also part of the specifications. 

The 2 solutions elaborated specified in TS 182 027 [2] and TS 182 028 [4] are IMS based IPTV and IPTV Dedicated 
Subsystem solutions but only the IMS based IPTV solution is considered in the present document. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 181 016: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN services and 
IPTV". 

[2] ETSI TS 182 027: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS 

subsystem". 

[3] ETSI TS 183 063: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification;". 

[4] ETSI TS 182 028: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IPTV Architecture; Dedicated subsystem for IPTV functions". 

[5] ETSI TS 183 064: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Dedicated IPTV subsystem stage 3 specification;". 
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[6] ETSI TS 185 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Customer Network Gateway Architecture and Reference 
Points;". 

[7] ETSI TS 185 006: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Customer Devices architecture and interfaces and Reference 
Points". 

[8] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture". 

[9] ETSI TS 181 005: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); Service and Capability Requirements". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 185 004: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); High level customer network architectures". 

[i.2] ETSI TS 185 005: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Services requirements and capabilities for customer networks 
connected to TISPAN NGN". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Customer Network Device (CND): physical device enabling service(s) usage 

NOTE: CNDs can be dedicated to the internet, conversational and audio-video services, but they could be also 
Consumer Electronics equipment and other devices which may have nothing to do with these premium 
services (e.g. services performing a content sharing within a CPN, typically between a PC and a music 
system, through the CNG). 

Customer Network Gateway (CNG): gateway between the Customer Premises Network (CPN) and the Access 
Network able to perform networking functions from physical connection to bridging and routing capabilities, but also 
possibly implementing functions related to the service support 

Customer Premises Network (CPN): in-house network composed by customer network gateway, customer network 
devices, network segments (physical wired or wireless connections between customer network elements), network 
adapters (performing a L1/L2 conversion between different network segments) and nodes (network adapters with L3 
routing capabilities) 

IPTV services Customer Network Device (IPTV-CND): physical device enabling consumption of IPTV service(s) 

NOTE: IPTV-CNDs are dedicated to the TV like audio-visual services such as live TV or On demand. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

CND Customer Network Device 

CNG Customer Network Gateway 
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CNGCF Customer Network Gateway Configuration Function 

COD Content On Demand 

CPN Customer Premises Network 

DHCP Dynamic Host Configuration Protocol 

IMS IP Multimedia Subsystem 

IPTV Internal Protocol Television 

NACF Network Access Configuration Function 

NAPT Network Address and Port Translation 

NAT Network Address Translation 

NPVR Network Personal Video recorder 

NTF NAPT Traversal Function 

P-CSCF Proxy Call Session Control Function 

QoE Quality of Experience 

QoS Quality of Service 

SIP Session Initiation Protocol 

SSF Service Selection Function 

STB Set Top Box 

UA User Agent 

UE User Equipment 



4 High level functional architecture for IPTV-CNDs 

The high level functional architecture of IPTV-CND is composed of 3 layers as represented in figure 4. 1 . 



4.1 Architecture layers 




Service Layer 



Transport Layer 



Figure 4.1 : Architecture layers 
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4.1.1 Transport layer 



This layer comprises functional entities that provide relevant IPTV transport level functions such as network attachment 
and media processing and streaming functions. 



4.1.2 Service layer 



This layer comprises functional entities that provide relevant IPTV functionality to applications above and also include 
entities that are used for management and control of platform itself. Depending on the type of services, the service layer 
entity must communicate either with other devices in the customer network or the external network using the transport 
layer. Service layer entities do not have a direct user interface and may be controlled via appropriate applications layer 
entities. 

Examples include: 

Media Management function. 

Service Discovery function. 

Platform security function. 

CA/DRM function. 

Configuration and Management function, etc. 

4.1 .3 Application and User Experience layer 

This layer comprises IPTV applications that have user interface (user driven input and /or output) and use the services 
provided by the underlying Service Layer to drive end user experience. 

Examples of applications include: 

• VOD. 

• Broadcast TV. 

• IPTV Service Guide interface, etc. 

The user may be a customer or a service operator. 

For the service operator, these functions may include service specific functions such as measurement applications 
(e.g. user satisfaction). 



4.2 IPTV operating modes 



IPTV CNDs can be simple terminals connected to the NGN or be part of a CPN in connection with the CNG. Different 
configuration are discussed in TR 185 004 [i.l]. Consequently, the IPTV CND can work in different modes in relation 
with the CNG. 

• Bridged mode: In this mode, the IPTV CND is working in compliance with TS 183 063 [3] and is connected 
to the NGN network or connects to the NGN via a CNG operating in bridged mode. In bridged mode of 
operation, the CNG provides only L1-L2 functionality. 

• Routed mode: In this mode, the IPTV CND connects to the NGN via a CNG operating in routed mode and is 
capable to interact with other devices in the CPN with other protocols above L3. In routed mode of operation, 
the CNG includes routing and service layer functionality as well (L3 and above). 

NGN mode: IPTV CND connects directly to the NGN through the CNG. 

CPN mode: the IPTV CND is interacting only in the domain of the CPN and all interactions with the 
access network are under control of the CNG. The CNG works in compliance with TS 183 063 [3] and is 
acting as an adaptor for all above L3 protocols to the CPN. 
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• Intra CPN mode: At service layer, the 2 devices interact with or without the support of the CNG. 

NOTE: Specifications for the intra CPN mode are not part of the present document but in this case, for example, 
IPTV CND could follow DLNA (Digital Living Network Alliance) interoperability guidelines. 



5 IPTV Customer Network Device Architecture 

The present document categorizes IPTV-CNDs into two types depending on TISPAN IPTV solutions that have been 
developed by WG2. They are: 

• Devices compatible with the IPTV dedicated subsystem solution. 

• Devices compatible with the IMS based IPTV solution. 

Devices compatible with IPTV dedicated subsystem solution: 

This category of IPTV CNDs includes IPTV capable device which can be utilized in conjunction with IPTV services 
deUvered in compliance with TISPAN specifications TS 182 028 [4] TS 183 064 [5]. 

Devices compatible with the IMS based IPTV solution: 

This category of IPTV CNDs includes IPTV capable device which can be utilized in conjunction with IPTV services 
delivered in compliance with TISPAN specifications TS 182 027 [2] for "IPTV functions supported by the IMS 
subsystem" for the architecture aspects and TS 183 063 [3] for protocols aspects. 

Only IMS based IPTV compatible devices are considered for detailed description in the present document. 

5.1 IIVIS based IPTV compatible devices 

IMS based IPTV compatible means compliance with TS 182 027 [2]. 
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5.1.1 



Detailed Architecture 
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Figure 5.1 : Detailed IPTV CND architecture 

NOTE: Entities in a given layer are interfacing/interacting with one or more functional entities in layers below it 
in order to accomplish the given function. Figure 5.1 does not depict all these internal 
interfaces / interactions which are implementation specific. 



5.1.1.1 



Transport Layer Functions 



5.1 .1 .1 .1 Network attachment functions 

IPTV CND attachment functions are compliant with the specifications for CNDs TS 185 006 [7]. They include: 

• IPTV-CND-CMF: Customer Network Device - Configuration and Maintenance Function. 

• IPTV-CND-AtF: Customer Network Attachment Function. 

• IPTV-CND-LAF: Customer Network Device - Local Authentication Function. 

5.1.1.1.2 Transfer functions 

IPTV CND transfer functions are compliant with the specifications for CNDs TS 185 006 [7]. 

• IPTV-CND-NTF : NAPT Traversal Function. 
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5.1.1.1.3 Transport functions 

5.1 .1 .1 .3.1 IPTV-CND-MPPF: IPTV Customer Network Device-Media Packet Processing Function 

The MPPF is the termination point for media flows encrypted or not encrypted, over the Dj interface connecting the UE 
to the NGN C-BGF as defined in ES 282 001 [8]. 

NOTE 1 : The handhng of encrypted media flows is out of scope of this release. 

NOTE 2: This function is providing support for NAT traversal such as the media port punching mechanisms and 
also for the usage of lGMPv3. 

5.1 .1 .1 .3.2 IPTV-CND-QOS: IPTV Customer Network Device-QoS Function 
The IPTV CND should support the following set of QoS functions for egress traffic: 

1) Traffic classification based on rules defined by the NGN service provider, access network provider or 
connectivity provider (business role definitions are defined in TS 181 005 [9]). 

2) Packet marking based on the different service classes. 

5.1 .1 .2 Service layer functions 

NOTE: The security aspects are not specified in this release. The term security is to be taken here in a general 
sense covering several aspects including content protection, conditional access, privacy and parental 
control. 

5.1 .1 .2.1 IPTV-CND-SIP UA : IPTV Customer Network Device SIP UA 

This block implements the Gm, Gm' interfaces on IPTV CND compatible with the IMS based IPTV solution. This SIP 
UA shall perform the service authentication and manage signalling flows securely following in that what is already 
described in clause 6 on Authentication in TS 185 006 [7]. 

5.1 .1 .2.2 IPTV-CND-SPM: IPTV Service Profile Management function 

This block implements the Ut interface; the Ut enables the access to an Application Sever to support the user in 
configuration services update. 

5.1 .1 .2.3 IPTV-CND-MDP: IPTV Customer Network Device MetaData Processing 

This functional entity utilizes Xa, Gm and/or Xd to receive service related metadata (e.g. IPTV services plans, EPG, 
VOD catalogue, customer applications). 

5.1 .1 .2.4 IPTV-CND-MPC: IPTV Customer Network Device Media Player Control 

This functional entity utilizes Xc for control of media delivery (e.g. RTSP set up. Play, stop, etc.). 

5.1 .1 .2.5 IPTV-CND-MD IPTV Customer Network Media Delivery 

This functional entity implements the Xd interface for the media streaming (e.g. RTP streams). 

5.1 .1 .2.6 IPTV-CND-CMM Configuration Management and Monitoring 

This function provides support for the IPTV-CND-CMF for service layer configuration, middleware management, 
performance monitoring (providing feedback on QoS/QoE including packet losses, packet delay and delay jitter, frame 
loss, pixilation) and diagnostics through the e3 reference point and e3' reference point. 
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5.1.1.2.7 



IPTV-CND-PPF: IPTV Customer Network Device - Plug and Play Function 



The CND-PPF in the CNG may exchange some device information (discovery, description) with other devices and 
allow their control. Particularly, the entity should allow a communication between many types of Customer Device 
within the CPN, based for instance on UPnP. 



5.1.1.2.7.1 



IPTV CND in routed NGN operating mode 



The IPTV CND shall be capable to operate the IPTV service as delivered by the IMS operator network. The CNG shall 
support the network attachment procedures and the transport functions. Additional functions may be present in the CNG 
and the IPTV CND to support multi service providers capabilities as well as local communications between the 
different devices of the CPN, including the CNG. 

The functions supporting these capabilities are already defined in: 

• TS 185 003 [6] as the CNG-PPF (CNG - Plug and Play function). 

• TS 185 006 [7] as the CND-PPF (Customer Network Device - Plug and Play function). 

• IPTV-CND-PPF : IPTV CND Plug and Play function. 
And the related reference point defined in: 

• TS 185 006 [7] Reference point C. 





IPTV CND 




c 




CNG 








CNG-PPF 

(Plug and Play 

Function) 






IPTV CND - PPF 

(Plug and Play 

Function) 

























Figure 5.2: Reference point C between CNG and IPTV CND 

Specific definitions of these functions for IPTV services are described hereafter. 

Role of IPTV CND Plug and Play function: collect and deliver information related to: 

• Content availability and description: There can be different format utilized in the CPN to represent these data. 
The Plug and Play function may include capabilities for converting data format. 

• Local user identity and related rules for content access: there may be local identity utilized only in the CPN. 
The Plug and Play function may include capabilities for managing local identities with IMS domain customer 
identities. 

• User interactivity related data to get control over resources and content selection and playing. Presentation data 
supporting user interactivity can be in different format. The Plug and Play function may include capabilities 
for adaptation of these data format. 

• Aggregation of content description data : content can be provided from outside by different service providers 
or can be stored locally. 
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5.1 .1 .2.8 IPTV-CND-cPVR: IPTV client PVR Function 

This functional entity has a normal PVR's capabilities, i.e. it records linear TV program and plays the recorded TV 
program; in addition, it provides also time-shift capability. 

The interface between IPTV application cPVR and the cPVR function is internal; therefore it can be proprietary. 

5.1 .1 .3 Applications and user experience layer functions 

The functions in this layer may be supported directly on the CND by native applications or they may be executed in a 
browser-based environment. Both types of applications may coexist on the CND implementing an hybrid concept. 

5.1.1.3.1 IPTV Applications 

The IPTV Applications provide support for a variety of IPTV Services and functions. They include: 

5.1 .1 .3.1 .1 IPTV-CND-CDA: The CoD Application 

This application function allows a user to select and control playback of a CoD stream. 

5.1 .1 .3.1 .2 IPTV-CND-BTA: Broadcast TV Application 

This application function allows a user to select a broadcast channel to view live/broadcast IPTV content. 

5.1 .1 .3.1 .3 IPTV-CND-NPA: N-PVR Application 

This application function allows users to schedule N-PVR capture requests. 

5.1 .1 .3.1 .4 IPTV-CND-CPA: client PVR Application 

This application function allows end-users to schedule client PVR for recording TV program and playing the recorded 
TV program and time-shift TV. 

5.1 .1 .3.2 IPTV-CND-SPA: Service Profile Application 

This application function allows users to manage IPTV service profile information. 

5.1 .1 .3.3 IPTV-CND-MDA: Metadata Application 

This functional entity enables the user to exchange service selection data/metadata (using the IPTV-CND-MDP) that 
enriches IPTV service experience and may be exchanged with the SSF (EPG guide, CoD catalogue, etc.), MDF or the 
SCF. 

Implementations of the IPTV-CND-MDA shall contain: 

• EPG services as required inTS 181 016 [1]. 
Implementations of the IPTV-CND-MDA may contain: 

• ESG services as required inTS 181 016 [1]. 

• Instant messaging services as required inTS 181 016 [1]. 

• Context aware messaging services (e.g. content recommendations) as required in TS 181 016 [1]. 

5.1 .1 .3.4 IPTV-CND-BF: Browser Function 

The Browser Function (BF) loads web based IPTV Application (for example, COD, Broadcast TV and NPVR) from the 
Service Selection Function (SSF) via the Xa reference point defined in TS 182 027 [2]. 
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It should be able to run IPTV applications (web based) for presentation of user interface and including scripting support 
for interaction at the underlying service layer functions (e.g. Media Player Control and Media Delivery, Metadata 
Processing, etc.). 

For example an application that runs in the BF can query (internally to the IPTV-CDN at the Metadata Processing 
Function) the Metadata-based Content Guide in order to extract any data it may contain. 



6 Reference points 

6.1 Reference points for IMS based IPTV compatible devices 
6.1 .1 Transport layer Reference points 

6.1 .1 .1 Transport Reference points 

Dj:This reference point is used to carry all data between the UE and the access point in the NGN. As such, in the case 
of IPTV CND, the Dj reference point is used to send and receive media data and media control flows to/from the NGN 
as specified in TS 182 027 [2]. The Dj reference point complies with the ES 282 001 [8] specifications. 

6.1 .1 .2 Network attachment Reference points 

el: This reference point between the IPTV-CND and NACF is used by the IPTV CND for attaching itself to the IMS 
IPTV service provider network. The usage of the el reference point conforms to TS 185 006 [7]. 

el': This reference point between the IPTV CND and CNG (in "routed NGN mode") provides network attachment 
functions and conforms to TS 185 006 [7]. 

e3: This reference point between IPTV-CND and CNGCF is used to remotely configure and manage the IPTV CND. 
The usage of the e3 reference point conforms to TS 185 006 [7]. 

e3':This reference point between the IPTV CND and CNG (in "routed NGN mode") provides device configuration 
functions and conforms to TS 185 006 [7]. 



6.1 .2 Service layer Reference points 



C: This reference point is between the Plug and Play function in the IPTV CND and the CNG-PPF in accordance with 
definition given in TS 185 006 [7] and TS 185 003 [6]. This reference point is optional and is used only in the Routed 
NGN mode and the Routed CPN mode. In these modes, the reference point C allows the establishing of a relationship 
between the CPN resources and the NGN; this relationship is based on exchange of information between CNDs and 
possibly the CNG in the CPN. 

Gm:This reference point between the IPTV CND and the NGN (P-CSCF) and conforms to TS 185 006 [7]. 

Gm':This reference point between the IPTV CND and CNG (in "routed NGN mode") conforms to TS 185 006 [7]. 

Xc:This logical end-to-end reference point between the IPTV-CND and IPTV Media Control Function is used for 
carrying media control messages. The usage of the Xc reference points conforms to TS 182 027 [2]. 

Xd:This logical end-to-end reference point between the IPTV-CND and IPTV Media Delivery Function is used for 
carrying the actual media. The usage of the Xd reference points conforms to TS 182 027 [2]. 

Xa:This reference point between IPTV-CND and SSF is used by the IPTV-CND to make appropriate service selections. 

Ut:This reference point between the IPTV-CND and IPTV Service Control is used for IPTV user profile configuration 
and conforms to TS 182 027 [2]. 

NOTE: The Xa' reference point between IPTV-CND and SDF used by the IPTV-CND to make appropriate 

service attachment is a non mandatory reference point defined in an informative annex of specifications 
TS 182 027 [2] and is for further study. 
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7 



The IPTV-CND Data Model 



The IPTV CND shall support the device data model for remote management as proposed by DSL Forum, the TR135 
model for STB published December 2007. 

Additionally, any relevant TR135 object extensions specified in TS 183 063 [3] required to support IPTV Service 
Provider / SDF Discovery as per "TR-069 Based SDF Discovery procedures" should be supported. 



8 



Deployment's scenarios 



In the CPN the IPTV service can be provided in at least two deployment's scenario. Below are two such options 
provided: 

• Option 1: All IPTV functionalities are implemented in the IPTV-CND. 

• Option 2: Some IPTV functionalities are implemented in the IPTV-CND and the others in the CNG. 



8.1 Option 1 



In the deployment's scenario "Option 1 " all functionalities described in the present document are implemented in the 
IPTV-CND. 



8.2 Option 2 



In the deployment's scenario "option 2", according to TS 185 003 [6], a subset of functionalities described in the present 
document are implemented in the IPTV-CND. 

Table 8.1 lists the functionalities that are implemented on the CNG and on the IPTV-CND. 

Table 8.1 : Deployment's scenario "option 2" 



Layer 


Function 


CNG 


IPTV-CND 


Transport 


Network Attachment: 

CMF- Configuration and Maintenance 

AfF- Attachment 

LAF- Local Authentication 


X 


X 


Transfer : 

NTF- NAPT Traversal 


X 




MPPF- Media Packet Processing Function 




X 


QoS- QoS Function 


X 


X 


IPTV Function (IGMP proxy, snooping, etc.) 


X 




Service 


SIPUA 


X 




SPM- Service Profile Management 




X 


MDP - Metadata Processing 


X 


X 


MFC - Media Player Control 




X 


MD- Media Delivery 




X 


CMM- Configuration Management and Monitoring 


X 


X 


CF (PPF) - Plug&Play Function 


X 


X 


Sec- Security Function 




X 


Application 


IPTV Application: 
IPTV-CND-CDA - CoD Appl. 
IPTV-CND-BTA - Broadcast TV Appl. 
IPTV-CND-NPA - N-PVR Appl. 
IPTV-CND-CPA - client PVR Appl. 




X 


SPA - Service Profile Appl. 




X 


MDA - Metadata Appl. 




X 


IPTV-CND-BF Browser Function 




X 


NOTE: X: means where (CNG or IPTV-CND) the functionality should be implemented, if it is present. 



The option 2 allows the IPTV-CND to use some functions present in CNG, e.g. SIP-UA, according to TS 185 003 [6]. 
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9 Information Flows 

NOTE: Information flows clause is non normative text reported in form of examples to better understand the 
relationships between the IPTV CND and the NGN, the CNG and other CNDs. 

The list of flows given hereafter is not exhaustive. 



9.1 



Information flows between IPTV-CND and NGN 



9.1.1 Example message flows on Xa 



IPTV-CND-MDP 



NGN-SSF 



(1) HTTP GET 



(2) 200 OK 



Figure 9.1 : Message flows for service selection 

The message flow in figure 9. 1 is an example of service selection function. 

With the HTTP GET, the CND asks the NGN for the program information, such as CoD catalogue, BC channels. And 
NGN returns the program information to the CND. 

This procedure example for service selection using HTTP is compliant with the specification TS 183 063 [3]. 

This procedure example is applicable for the IPTV-CND in the bridged mode. 



9.1 .2 Example message flows on Ut 



IPTV-CND-SPM 



NGN-SCF 



(1) HTTP GET 



(2) 200 OK 



(3) HTTP PUT 



(4) 200 OK 



Figure 9.2: Message flows for service related information configuration 

The message flow in figure 9.2 is an example of service related information configuration function. 
With HTTP GET and PUT methods, the CND retrieves and modifies its service related information. 
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The procedure example for service related information configuration using HTTP is compliant with the specification 
TS 183 063 [3]. 

This procedure example is applicable for the IPTV-CND in the bridged mode. 

9.1 .3 Example message flows on Gm 

9.1.3.1 Registration 

The NGN registration flows are compliant with the specification TS 183 063 [3]. 

9.1 .3.2 Session Initiation and Termination 

The Session Initiation and Termination flows are compliant with the specification TS 183 063 [3]. 

9.1 .3.3 IPTV Service Action Data Delivery 

The IPTV service action data delivery flows are compliant with the specification TS 183 063 [3]. 















IPTV-CND-SIP UA 




NGN-P-CSCF 








(1) SIP INFO 


r MESSAGE 










(2) 200 OK 















Figure 9.3: Message flows for IPTV service action data delivery 

IPTV service action data, such as BC bookmarks, Available CoD and NPVR items, are delivered to CNG-SIP via SIP 
INFO or MESSAGE method. 

This procedure example for service action data delivery is compliant with the specification TS 183 063 [3]. 

This procedure example is applicable for the IPTV-CND in the bridged mode. 
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9.1 .4 Example message flows on Xc and Xd 

IPTV application utilizes Xc for media control, such as RTSP setup, play, teardown, and utilizes Xd for media 
streaming, such as RTP stream. 



9.1.4.1 



Message flows for CoD service 



IPTV-CND-MPC 



MF 



(1) RTSP SETUP 



(2) 200 OK 



(3) RTSP PLAY 



(4) 200 OK 



(5) RTP/RTCP 



< 



> 



(6) RTSP TEARDOWN 



(7) 200 OK 



Figure 9.4: Information flows for media content control and delivery 

This procedure example for media control using RTSP is compliant with the specification TS 183 063 [3]. 
This procedure example is applicable for the IPTV-CND in the bridged mode. 



9.1.4.2 



Message flows for BC service 















IPTV-CND-MPC 




MF 








(1) Join Multicast Gi 


roup 


^ 








(2) RTP/RTCP 




< > 


(2) Leave Multicast Group 













Figure 9.5: Information flows for media content control and delivery 

This procedure example for media streaming using IGMP is compliant with the specification TS 183 063 [3]. 
This procedure example is applicable for the IPTV-CND in the bridged mode. 
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9.1 .5 Example message flows on es 



IPTV-CND-CfM 



CNGCF 



(1) HTTP GET 



(2) 200 OK 



Figure 9.6: Message flows for configuration and management 

IPTV applications utilize 63 for auto-configuration, software management and diagnostics. 
This procedure example is applicable for the IPTV-CND in the bridged mode. 



9.1 .6 Example message flows on e 



IPTV-CND-AtF 



ARF, NACF 



(l)DHCPDISCOVER 



(2) DHCPOFFER 



(3) DHCPREQUEST 



(4) DHCPACK 



(5) DHCPRELEASE 



Figure 9.7: IVIessage flows for network attachment 

1) The CND broadcasts a DHCPDISCOVER message with its client identifier and some request parameters, 
such as Domain name and P-CSCF address etc. 

2) Multiple DHCP servers return DHCPOFFERs with parameters to the CND. 

3) The CND choose one DHCPOFFER, and broadcasts DHCPREQUEST message with configuration 
parameters. 

4) The DHCP server selected in the DHCPREQUEST message commits the binding and responds with a 
DHCPACK message containing the configuration parameters for the CND. 

5) The CND receives the DHCPACK message with configuration parameters. At this point, it is configured. 
The CND may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to 
the server. 

The client identifier is unique within its subnet. It may contain a hardware address. For a UPnP device, a unique device 
name can be chosen as its client identifier. 

This procedure example is applicable for the IPTV-CND in the bridged mode. 
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9.2 



Information flows between IPTV-CND and CNG 



9.2.1 Example message flows on C 



In UPnP environment, the control point can retrieve the information of device of interest. The information includes the 
device description and service description describing the capabilities exposed by the device. After getting this 
information, control point sends suitable control message to perform control action. 

This following message flow gives an example of device information exchange and device control based on UPnP 
enabled devices. 



9.2.1.1 



Message flows for device and service information exchange 



The information includes the device description and service description describing the capabilities exposed by the 
device. Two cases are shown in Figures 9.8(a) and 9.8(b) respectively. 















IPTV-CND-PPF 




CNG-PPF 








(1) NOTIFY 












(2) HTTP GET 




(3) Response 


(4) HTTP GET 


(5) Response 













Figure 9.8(a): Message flows for device information exchange based on UPnP 

In figure 9.8(a) 

1) When the CNG is added to the network, it multicasts a number of discovery message advertising itself. The 
interested control point IPTV-CND can listen to the standard multicast address for notifications that new 
capabilities are available. 

2) IPTV-CND retrieves the device description of the CNG by issuing an HTTP GET request to the URL in the 
NOTIFY request from the CNG. 

3) The CNG returns its device description in the body of the HTTP response. 

4) The IPTV-CND retrieves the service description of the CNG by issuing an HTTP GET request to the URL in 
the device description of the CNG. 

5) The CNG returns description of the service description in the body of the HTTP response. 
This procedure example is applicable for the IPTV-CND in the routed mode. 



£75/ 



22 



ETSI TS 185 009 V2.1.1 (2008-07) 















IPTV-CND-PPF 




CNG-PPF 








(l)M-SEARCH 




^ 








(2) Response 




(3) HTTP GET 


(4) Response 


(5) HTTP GET 


(6) Response 













Figure 9.8(b): Message flows for device information exchange based on UPnP 

In figure 9.8(b) 

1) When the IPTV-CND is added to the network, it muhicasts a discovery message searching for interesting 
devices. 

2) The CNG Hstens to the standard multicast address for these messages and finds itself matching the search 
criteria in the discovery message. The CNG responds with its unique service name and location. 

3) 4) 5) 6) are similar to 2) 3) 4) 5) in figure 8.8(a) respectively. 

This procedure example is applicable for the IPTV-CND in the routed mode. 



9.2.1 .2 Message flows for device control 















IPTV-CND-PPF 




CNG-PPF 








(l)POST 












(2) Response 















Figure 9.9: lUlessage flows for device control based on UPnP 

The capabilities exposed by CNG are various, such as QoS provisioning, local user identity etc, clause 6.1.3 gives the 
details. All these capabilities can be defined in its service description and be performed by sending control message 
using SOAP. 

1) IPTV-CND-PPF invokes a POST request to the CNG-PPF and waits for the response. The SOAP message 
containing the value of input parameters is embedded in the HTTP request. 

2) The CNG-PPF performs the requested control action and returns the response with SOAP message 
embedded to the IPTV-CND-PPF. 

This procedure example is applicable for the IPTV-CND in the routed mode. 
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9.2.2 Example message flows on Gm' 

9.2.2.1 Registration 

The NGN registration flow is compliant with the specifications for CNDs TS 185 006 [7] in clause 8.3.1. 

9.2.2.2 IPTV Service Action Data Delivery 















IPTV-CND-SIP UA 




CNG-SIP 








(1) SIP INFO 


r MESSAGE 


^ 








(2) 200 OK 















Figure 9.10: Message flows for IPTV service action data delivery 

IPTV service action data, such as BC bookmarks, Available CoD and NPVR items, are delivered to CNG-SIP via SIP 
INFO or MESSAGE method. 

The procedure example for service action data deUvery is compliant with the specification TS 183 063 [3]. 

This procedure example is applicable for the IPTV-CND in the routed NGN mode. 

9.2.3 Example message flows on ei' 

The message flows on e,' are compliant with the specifications for CNDs TS 185 006 [7] in clause 8.1. 

9.2.4 Example message flows on es' 

The message flows on e3' are compliant with the specifications for CNDs TS 185 006 [7] in clause 8.2. 

9.2.5 Example message flows on a^ 



IPTV-CND-LAF 



CNG-AuF 



(1) Request for CPN connection 



< 



(2) Authentication procedure 



> 



Figure 9.11 : Information flows for IPTV CND connecting to CPN 

This procedure example is applicable for the IPTV-CND in the routed mode. 
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